Fast Backward Congestion Notification Mechanism for TCP Congestion Control

This paper proposes a novel fast backward congestion notification mechanism for TCP congestion control. The proposed method uses a simple implementation to inform the traffic source at a very early stage that the network is becoming overloaded or congested and ask the source to slow down its transmission rate. Since TCP uses acknowledgments (ACKs) to adjust the number of packets sent over the network, the basic idea of our scheme is to control (or delay) TCP ACKs in the access node where its forward connection through the network is congested. To shorten the control loop, the congested network node generates ICMP Source Quench to initiate ACK control at the access node at the onset of congestion. The mechanism is proven very effective to improve TCP throughput and fairness performance and reduce buffer occupancy, by theoretical analysis and simulations. In particular, formulae for buffer occupancy and average throughput are derived relative to the distance between the congested node and the source terminal. It is important to note that TCP behavior does not have to be amended in any way. 1. Background and Motivations TCP is one of the few transport protocols that have their own congestion control mechanisms. The TCP flow control mechanism is meant to slow down the source rate when the network becomes congested. It has no direct way of knowing when the network is congested and can only indirectly detect congestion by keeping track of packet loss. This reliance on packet drops as an indication of congestion causes congestion control to be initiated after congestion losses have already happened. Because retransmissions of lost packets are scheduled with a backoff delay equal to twice the current (estimated) round trip time (RTT), throughput decreases as the end-to-end delay increases. Besides, depending on when congestion hits, packet dropping may come too late if the source has already sent out all the data it intended to. To avoid unnecessary packet drops and therefore avoid unnecessary delays for packets from lowbandwidth delay-sensitive TCP connections, an Explicit Congestion Notification (ECN) mechanism is being considered by IETF [3]. When the buffer of a router’s outgoing link is about to overflow, it sets the ECN bits in the forwarded packets as an indication of congestion. When each packet reaches its destination, the congestion indication is turned around by the receiving terminal and returned to the source by setting the ECN bit in the next outgoing ACK packet. In this way, it can avoid congestion in asymmetric networks. However, the source has to wait one RTT before responding to an ECN indication as it has the same control loop as TCP. Implementing the congestion control algorithm at the source and processing congestion-related notifications at the receiver clearly need modifications of TCP behavior at end systems. Compared to ECN, mechanisms based on the idea of delaying reverse ACKs have been proposed to reduce the sending rates of TCP sources in case of congestion. Generally, the delayed ACK algorithm is implemented in TCP receivers [4]. This requires a round-trip control time and the TCP behavior at receiver has to be modified. In addition, without any knowledge of network conditions, it is difficult to determine when the receiver should send ACKs. Fast-TCP (FTCP) proposed by Nokia requires no TCP modifications since it executes ACK control in the network node where the forwarding data buffer becomes congested. However, it requires that ACKs be routed through the same nodes as their corresponding forward packets. Except the access nodes, the backward ACK’s are often routed through different intermediate nodes than its corresponding forward packet. This limits the usefulness of FTCP even though it has been proven to work well in access nodes [5, 6]. Another mechanism called TCP rate control was proposed to employ ACK control at intermediate nodes to smooth the traffic flow without incurring retransmission timeouts [9]. However, different from FTCP, it does not rely on monitoring queue status and manages the TCP transmitter directly by taking over TCP flow control. By optimally pacing transmissions of ACKs, TCP rate control provides direct feedback to the transmitter by detecting a remote user’s access speed and the network’s latency. In this way, it can maintain flow and connection status, monitor a connection’s speed and adjust bandwidth allocation as the connection speed changes. However, TCP rate control is a proprietary solution that is not compatible with standard TCP behavior and is complex to implement. From the above, we see that it is advantageous to develop a congestion control mechanism with a shortened control loop that requires no modifications of end-system TCP behavior. This paper presents such a mechanism referred as Fast Backward Congestion Control (FBCN) (see Fig. 1). The remainder of the paper is organized as follows. Section 2 introduces the FBCN mechanism. Section 3 presents the system model and parameters used for evaluations in subsequent sections. In section 4, we deduce a set of analytical expressions and provide simulation results characterizing the steady state system performance for a single connection. In section 5, we present and discuss the results for multiple connections. Section 6 concludes the paper. 2. Fast-Backward Congestion Notification Mechanism For simplicity, we consider that the network indicates congestion only to the access node where data transmission rate will be controlled to shorten the control loop. The ICMP Source Quench (ISQ) message is used for congestion notification to minimize modifications of current routers. Assuming the participating routers are capable of random error detection (RED) or some other active queue management methods, instead of dropping packets, ISQ messages are generated and immediately sent back to the sources by the router as an indication of incipient congestion. We propose to use the currently unused field of ISQ messages (bit 5, see [9]) as the FBCN bit. Two kinds of ISQ messages are used in FBCN: one to indicate congestion with FBCN bit set to 1, and the other to indicate the end of congestion with FBCN bit reset to 0 (see Fig. 2). The FBCN bit should not be changed or erased by the nodes as the ISQ messages travel through the network in the backward direction. Since TCP uses receiver window size to bind the number of packets that could be in the receiver buffer at any time, our mechanism will not affect TCP behavior at the receiver. With the proposed FBCN mechanism, the access node is responsible for providing congestion control feedback to the source because it is the network node nearest to the source and the common node through which forward data packets and their corresponding ACKs pass. In addition to examining its own buffer occupancy, the access node also determines if the FBCN bits of received ISQ packets are set. To keep congestion notification at the network (IP) level, once the ISQ messages have reached their respective access nodes to TCP Source LAN LAN